1. Field of the Invention
The present invention relates to a demultiplexer capable of separating desired packets from (a bit stream of) input digital data which has different types of packets multiplexed by a specific multiplexing method. More particularly, it relates to a demultiplexer provided with a command memory in which micro-codes are stored for controlling the action of each components in response to the micro-codes read out in a sequence from the command memory. As a result, the demultiplexer can handle different type of the multiplexing format through modifying the micro-codes read from the command memory, thus decreasing the overall size of its circuit and the overall cost.
2. Description of the Related Art
In general, video, audio, text, and other contents of digital data for the broadcasting and the storage mediums are encoded and multiplexed through grouping into packets or packs before transmitted and stored in the form of a stream of bits. When the packets in the received data are identical in the encoding format but different the multiplexing format, the receiver has to prepare a plurality of demultiplexers for the different types of the multiplexing format.
For example, the technologies of DVB (digital video broadcasting), DSS (digital satellite system), and DVD (digital versatile disc) are different from each other in the multiplexing format.
FIG. 19 illustrates a common structure of the DVB packet in a DVB stream. The DVB packet comprises a header of 4 bytes, an adaptation field of a variable length, and a payload of a variable length (a data field) and its total length is 188 bytes. As well known, the payload contains PES (packetized elementary stream) packets separated again and assigned as well as various table of PSI (program specific information) in the form of sections determined by the MPEG2 system. The DVB packet may be composed of either the adaptation field or the payload. The header contains a PID (packet identification) data for the packet identification, while the adaptation field contains a PCR (program clock reference) data as the timing information.
FIG. 20 shows the contents of the header in the DVB packet. “Sync—byte” is 0×47. When “transport—error—indicator” is 1, it indicates that the packet has an error. When “payload—unit—start—indicator” is 1, it indicates that the payload in the packet is marked with the PES or PSI header. When “transport—scrambling—control” is 00, it indicates that the packet is not scrambled. When the upper bit in “adaptation—field—control” is 1, it indicates that the packet contains the adaptation field. When the lower bit in the same is 1, it indicates that the packet contains the payload. “Continuity—counter” is provided for examining whether or not more than one of packets having the same PID data are arranged consecutively.
FIG. 21 illustrates the major contents of the adaptation field. “adaptation—field—length” indicates the length of the adaptation field. When “adaptation—field—control” is 10, 0×B7 (=183) is established. When “PCR—flag” is 1, it indicates that the adaptation field contains a PCR data as the timing information.
FIG. 22 illustrates a common structure of the DSS packet in a DSS bit stream. The DSS packet comprises a prefix of 2 bytes and a transport block of 128 bytes and its total length is 130 bytes. The prefix contains a SCID (service channel identification) data for the packet identification while the transport block contains the timing information.
FIG. 23 shows the major contents of the prefix in the DSS packet. “Packet Framing” is tuned to 0 or 1 alternately in each packet. When the packet is scrambled, “Control Flag” is 0. If not, 1. FIG. 24 illustrates one byte of a CC field and an HD field after the prefix. “Continuity Counter” is provided for examining whether or not more than one of packets having the same SCID are arranged consecutively. “Header Designator” is provided for indicating the type of a video application packet.
For example, when the packet is an Auxiliary Data packet, “Header Designator” is 0000. Simultaneously, “Continuity Counter” is 0000. FIG. 25 shows 2 bytes after the CC field and the HD field in that case. When “Current Field Flag” is 1, it indicates that the Auxiliary Data packet is valid. “Aux Field ID” indicates what is contained in the Auxiliary Data packet. When 000000, the Auxiliary Data packet contains 5 bytes of a RTS (reference time stamp) data as the timing information. When 000011, the same packet contains the RTS data and an “Encryption Control Word Packet”.
FIG. 26 illustrates a common structure of the DVD pack in a DVD bit stream. The DVD pack comprises a pack header of a variable length, a system header of a variable length, and a PES packet of a variable length and its overall length is variable. The PES header contains a stream ID as the packet ID and the pack header contains a SCR (system—clock—reference) data as the timing information.
FIG. 27 illustrates the major contents of the PES header. “PES—start—code—prefix” is always 0×000001, indicating the start of the PES header. “PES—packet—length” indicates the length of the succeeding PES packet. “PES—header—data—length” indicates the length of “optical PES header” following “stream—ID”.
FIG. 28 illustrates the major contents of the DVD pack header. “pack—start—code” is 0×000001BA. “system—clock—Reference—base” and “system—clock—Reference—extension” are the timing information. The system header follows the pack header of the first pack. FIG. 29 shows the major contents of the system header.
As the multiplexing formats are different, the construction of the streams, the contents of the headers, and the other settings become non-uniform. Accordingly, the header analysis and the payload transmission have to be modified depending on the multiplexing format.
FIG. 30 illustrates an arrangement of a demultiplexer 200 designed for separating desired packets for output from a bit stream of input digital data which has different types of packets multiplexed.
The demultiplexer 200 comprises an input terminal 201 for receiving a bit stream STM, a header analyzer 202 for analyzing the header of each packet or pack contained in the bit stream STM using a sequencer, an output destination determining unit 203 for determining the destination of outputting each packet, and a system clock controller 204 for controlling a system clock with the timing information extracted from the bit stream STM in the header analyzer 202.
The output destination determining unit 203 has a built-in memory (not shown) thereof provided in which packet ID data have been registered for identifying the packets to be extracted from the bit stream STM. The packet ID may be received via a host interface 205 from an external CPU. When it is found by the header analyzer 202 that the packet ID extracted from a packet matches the packet ID stored in the built-in memory, the output destination determining unit 203 determines a destination identified by the stored packet ID as the destination of the packet having the extracted packet ID.
The demultiplexer 200 also includes a separator 206 for separating the destined packets from the bit stream STM and transferring them to the destination. The separator 206 may be connected to a set of output terminals 207a, 207b, 207c, and so on as the destinations.
When the bit stream STM is of the DVB format, the demultiplexer 200 shown in FIG. 30 carries out a procedure of packet processing shown in the flowchart of FIG. 31.
The procedure starts with receiving a DVB packet at Step ST11 and detecting a synchronous byte “sync—byte” in the packet at Step ST12. At Step ST13, the header is examined at “transport—error—indicator”, “transport—scrambling control”, “adaption—field—control”, and the like whether or not they contain any error. If not, the procedure goes to Step ST14.
At Step ST14, it is examined whether the PID data in the header is identical to the PID data stored in the built-in memory of the output destination determining unit 203. When the PID data in the header is identical to the one stored, a continuous index “continuity—counter” in the header is examined at Step ST15 whether or not the continuity of the packets is established. When so, the procedure advances to Step ST16.
At Step ST16, it is examined whether the PCR data as the timing information is contained or not. When the timing information is contained, the procedure goes to Step ST17. At Step ST17, the timing information is extracted from the packet and transferred to the system clock controller 204. This is followed by Step ST18. If the timing information is not found, the procedure jumps to Step ST18. At Step ST18, the payload in the packet is transmitted to the destination determined by the PID data of the header before repeating the procedure for the succeeding DVB packet.
When it is found at Step ST13 that the header contains an error, the PID data of the header is not identified at Step ST14, and the continuity is not found at Step ST15, the packet is discarded at Step ST19 before repeating the procedure for the next DVB packet.
When the bit stream STM is of the DSS format, the demultiplexer 200 shown in FIG. 30 carries out a procedure shown in the flowchart of FIG. 32.
The procedure starts with receiving a DSS packet at Step ST21 and detecting a synchronous signal in the packet at Step ST22. At Step ST23, the prefix is examined for error bits (in “control—flag” or the like). If no error is found, the procedure goes to Step ST24.
At Step ST24, it is examined whether the SCID data in the prefix is identical to the SCID data stored in the built-in memory of the output destination determining unit 203. When the SCID data in the prefix is identical, “continuity—counter” in the prefix is examined at Step ST25 whether or not the continuity of the packets is established. When so, the procedure advances to Step ST26.
At Step ST26, it is examined whether the RTS (reference time stamp) data as the timing information is contained or not. When the timing information is contained, the procedure goes to Step ST27. At Step ST27, the timing information is extracted from the packet and transferred to the system clock controller 204. This is followed by Step ST28. If the timing information is not found, the procedure jumps to Step ST28. At Step ST28, the transport block in the packet is transmitted to the destination determined by the SCID data of the prefix before repeating the procedure for the succeeding DSS packet.
When it is found at Step ST23 that the prefix contains an error, the SCID data is not identified at Step ST24, and the continuity is not found at Step ST25, the packet is discarded at Step ST29 before repeating the procedure for the next packet.
When the bit stream STM is of the DVD format, the demultiplexer 200 shown in FIG. 30 carries out a procedure shown in the flowchart of FIG. 33.
The procedure starts with receiving a DVD pack at Step ST31 and detecting a start code “pack—start—code” in the packet at Step ST32. At Step ST33, the SCR data is extracted as the timing information from the pack header and transmitted to the system clock controller 204. Then, the procedure goes to Step ST34.
At Step ST34, it is examined whether the pack is the first pack or not. When so, the system header is transmitted to the corresponding destination at Step ST35 and then, the procedure advances to Step ST36. If not the first pack, the procedure jumps to Step ST36.
At Step ST36, each PES packet is extracted and transmitted to the destination determined by the Stream ID in the header before repeating the procedure for the next pack.
As described above, for handling the signals of the different multiplexing formats which are different in the construction of a bit stream and the analyzing process of each header, a corresponding number of the demultiplexers 200 are needed. Accordingly, the hardware circuitry arrangement for handling the different type of the multiplexing format with their dedicated circuits will be increased in the overall size and the production cost.